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Abstract — We present a new type of clogging DoS attacks, with 
the highest amplification factors achieved by off-path attackers, 
using only puppets, i.e., sandboxed malware on victim machines. 
Specifically, we present off-path variants of the Opt-ack, Ack- 
storm and Coremelt DoS attacks, achieving results comparable 
to these achieved previously achieved by eavesdropping/MitM 
attackers and (unrestricted) malware. In contrast to previous 
off-path attacks, which attacked the client (machine) running the 
malware, our attacks address a very different goal: large-scale 
clogging DoS of a third party, or even of backbone connections. 

Our clogging attacks are based on off-path TCP injections. 
Indeed, as an additional contribution, we present improved 
off-path TCP injection attacks. Our new attacks significantly 
relax the requirements cf. to the known attacks; specifically, 
our injection attack requires only a Java script in browser 
sandbox (not 'restricted malware'), does not depend on specific 
operating system properties, and is efficient even when client's 
port is determined using recommended algorithm. Our attacks 
are constructed modularly, allowing reuse of modules for other 
scenarios and replacing modules as necessary. We present specific 
defenses, however, this work is further proof to the need to base 
security on sound foundations, using cryptography to provide 
security even against MitM attackers. 

I. Introduction 

As the importance of the Internet grows, there is higher risk 
in disruption of its services, i.e., perform Denial/degradation 
of Service (DoS) attacks; already we see DoS attacks becoming 
a significant concern, with different motivations, including 
criminal, ideological ('hacktivism') and even as part of cy- 
berwarfare. We focus on DoS attacks which are based on 
network clogging, i.e., disrupting network services by causing 
excessive traffic; these attacks do not depend on vulnerabilities 
of the victim network or application. Network clogging DoS 
attacks are becoming larger and more common, and becoming 
a significant concern to corporations and even governments. 
Recent reports indicate attack rates in the order of 100 
Gbps[5]; 60-86.5% of the attacks targeted the infrastructure 
(layer 3), including the mitigation infrastructure itself [ 15 1, 
which is mostly based on providing overcapacity upon attack. 

All clogging attacks are based on sending information from 
many malicious agents; such agents are normally malware run- 
ning on user machines, ranging from fully-privileged malware 
to limited-privileges malware (e.g., Android application) and 
to puppet, i.e., malware running within standard sandbox (such 
as script or applet). It is easier for attackers to collect puppets 
which are malicious scripts running in a browser's sandbox 
[4 1, these only require users accessing the attacker website. 

In this paper, we show that even such mere puppets can be 
abused to launch devastating clogging DoS attacks. The attacks 
we present exploit behaviors of the Transmission Control Pro- 
tocol (TCP), or more precisely, exploit puppets running TCP 



on different client machines, to cause huge amounts of traffic 
leading to congestion. TCP is the main transport protocol 
over the Internet, ensuring reliable communication between 
applications; in particular, puppets are usually restricted to 
communication using standard TCP stacks, except possibly for 
communication to the site sending the malware. This makes 
it challenging to use puppets for clogging attacks, since TCP 
responds gracefully to congestion to ensure fair and efficient 
sharing of network resources. 

Trivially, a MitM attacker can eavesdrop, block, modify 
and inject fake TCP traffic; such attacker does not need any 
client agents to perform DoS (and other) attacks. However, we 
consider the weaker - and more common - off-path attacker, 
who can only send spoofed packets, and cannot block, inter- 
cept or modify traffic. We show that even such weak attacker, 
can exploit puppets to cause wide-scale congestion, with very 
high amplification factor (i.e., a relatively modest number of 
puppets suffice to clog large network links). 

Specifically, we show how puppets can be used to launch 
the two clogging-DoS attack which have the highest impact 
(amplification) so far, the Opt-Ack attack [24] and the Ack- 
storm attack Q, but using only puppets and an off -path 
attacker (instead of requiring privileged malware and weak- 
eavesdropping abilities, as in the original attacks). Further- 
more, we explain how such attacks on specific connections, 
can be combined to create effective congestion disrupting 
connectivity of whole regions, extending and improving upon 
the Coremelt attack 11251 . again requiring only puppets and 
an off-path attacker, instead of the original requirement of 
privileged malware. 

The basic idea of our attacks is to use the off-path attacker 
to send conttol packets to the TCP connection between puppet 
and server, playing the role of the malicious client in Opt-Ack 
and of the eavesdropping attacker in the Ack-Storm attack. To 
do this, our attacker must be able to inject traffic into the TCP 
connection; this is not trivial, since puppets are not given the 
necessary information about a connection, such as the client, 
port and sequence numbers (of the client and the server). 
We show, however, that the attacker can obtain all necessary 
information for the attack, namely, efficiently perform an off- 
path TCP injection attack into the connections between the 
puppets and the servers. 

Our attacks can target either end of the TCP connection 
(client or server). The injected data is of TCP conttol plane; 
hence, these attacks hold even if the SSL/TLS protection is 
employed. We show in experiments that using a relatively 
small set of low-privileged malicious agents, e.g., scripts in 
browser sandbox, the off path attacker can cause large amounts 
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of traffic leading to congestion. 

A. Off-path TCP Injection Attacks 

Over the years, TCP specifications and implementations 
were enhanced to provide security against off-path attacks. 
TCP implementations should randomize the 32-bit sequence 
number (6) and the 16-bit client port fl9l ; for successful 
injection, the adversary must provide valid values to these 
fields. Since the adoption of randomized initial sequence 
numbers and until recently, TCP was widely believed to be 
immune to off -path (injection) attacks. One exception was the 
off-path attacks on TCP of E71l . which disconnected BGP 
connections that use constant client ports; countermeasures 
make this attack inapplicable today iflOll . However, this attack 
was considered as reflecting a very specific vulnerability 
of BGP availability, and the widespread belief was that an 
'off-path' spoofing attacker, cannot inject traffic into a TCP 
connection, since it is infeasible for the attacker to guess 
correct client port and sequence number. This belief is even 
stated in RFCs and standards, e.g., in RFC 4953, discussing 
on TCP spoofing attacks (see |26|, Section 2.2). Indeed, since 
its early days, most Internet traffic is carried over TCP - and 
is not cryptographically protected, in spite of warnings, e.g., 
by Morris EO) and Bellovin Q, 0. 

The first 'proof of concept' showing that TCP injection 
attacks may still be possible, even with randomly-chosen 
initial sequence numbers, was in 1181 . This was recently 
improved into efficient off-path TCP injection attacks [22|, 
[13 1, l23l : we could use these techniques to achieve our off- 
path clogging attacks. 

However, these existing attacks are limited, specifically, 
both 1 22 1 and 1 23 1 require malware rather than puppets on the 
client machine (albeit with limited privileges), while lfT3l ex- 
ploits the use of globally-incrementing allocation mechanisms 
for both ports and IP-IDs, as exists in the popular Windows 
operating systems. 

We present new variants of TCP injection attacks, with 
further improved efficiency and avoiding both malware and 
globally-incrementing IP-ID and ports assumptions (see com- 
parison in Table |T]>. Although Windows is very popular, avoid- 
ing the globally-incrementing requirements still significantly 
expands the base of clients which can be exploited for the 
clogging attack; furthermore, these specific weaknesses may 
be removed in future versions of Windows. Our new attacks 
can also be used to extend the XSS, CSRF and phishing attacks 
of E2l . ifPTl . E3l to these additional scenarios (puppet rather 
than malware and avoiding the requirement of Windows- 
specific properties). 

B. Attacker and Network Model 

Mallory, the attacker that we consider, is an off-path spoof- 
ing attacker. Mallory cannot observe traffic sent to others; 
specifically, she cannot observe the traffic between a client 
C and a server S. However, Mallory can send spoofed packets, 
i.e., packets with fake (spoofed) sender IP address. Due to 
ingress filtering IfTTl and other anti-spoofing measures, IP 



New connection formed, 
HTTP referrer: mallory.com o 
• ► 




mallory.com 



Fig. 1. Network Model. C enters www.mallory.com, the adversarial web 
page. A script on that page forms a connection with www. s. com. 



spoofing is less commonly available than before, but still 
feasible, see 0, IfTTl . Apparently, there is still a significant 
number of ISPs that do not perform ingress filtering for their 
clients (especially to multihomed customers). Furthermore, 
with the growing concern of cyberwarfare, some ISPs may 
intentionally support spoofing. Hence, it is still reasonable to 
assume spoofing ability. Spoofed packets were used in many 
other attacks, including SYN-flood, DNS-poisoning and both 
previous off-path injection attacks. Figure [T] illustrates our 
model. 

C. Contributions 

This first contribution of this paper, is in presenting the very 
effective off-path clogging DoS attacks, significantly more 
efficient than previously known off-path clogging attacks such 
as DNS reflection attacks. Furthermore, our attacks are the first 
to show that off-path clogging can utilize TCP traffic. 

Third, we investigate off-path variants to previous DoS 
attacks which were known to require stronger adversaries: 
either man-in-the-middle, or control of client end (i.e., bot). 
We present an algorithm that allows an off-path adversary 
to perform the Coremelt attack and disconnect a targeted 
autonomous system from the Internet. We show that this 
attack has significantly lower requirements (of the number and 
location of agents) from the original Coremelt attack. 

A second contribution allows an off-path attacker to effi- 
ciently detect the client source port, if the client's operating 
system uses the Simple Hash-Based Port Selection Algorithm 
recommended in |fl9l . This mechanism is deployed in Linux 
and is extensively used, e.g., by Android; moreover, many 
clients connect to the Internet via NATs, these devices com- 
monly run Linux and use this selection algorithm for the 
external port, making it the de-facto port selection algorithm of 
many clients. Detection of the source port is a necessary first 
step for efficient TCP injection, but also has additional security 
implications, in particular, allowing traffic analysis (detection 
of which clients connect to a server), as investigated in |14|. 

Our third contribution is a new, efficient off-path TCP injec- 
tion attack, where an off -path adversary leams both the server 
and client's sequence numbers of the connection using only 
a puppet. This improves over 11221 . 11231 that assume malware 
running on the victim machine (although with low privileges) 
and only exposes the server's sequence number. Our attack 
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Identify Victim-Connection 


Learn Victim-Connection Sequence Numbers 


Shown Exploit 


Lkm QU 


Probe for connection 
(Client runs Windows, no firewall) 


IP-ID side channel, 
both seq. # obtained 
(Client runs Windows) 


None 


Zhiyun et al. l22l. (23l 


Monitor Connections with netstat/procfs 
(Malware) 


Exploit seq # filtering, 
only server's seq. # obtained 
(Malware; in 1221 also sequence-checking firewall) 


XSS, CSRF 
(Malware, No TLS/SSL) 


Gilad et al. QU 


Establish connection, exploits 

sequential port allocation 
(Puppet, client runs Windows) 


IP-ID side channel, 
both seq. # obtained 
(Puppet, client runs Windows) 


XSS, CSRF, phishing 
(Puppet, no TLS/SSL) 


This work 


Establish connection, 
Timing side-channel 
(Puppet) 


"Inject and Observe", 
both seq. # obtained 
(Puppet, no TLS/SSL) 


Denial of Service 
(Puppet) 



TABLE I 

Off-Path TCP Injection Attacks, Building Blocks and their Requirements (Specified in Brackets). 



is also not specific to TCP implementation (platform) as the 
technique in ff3l . 

One last contribution is in introducing and modeling the 
problem of clogging DoS attack optimization, which provides 
a better measure of the potential risk of clogging due to 
coordinated attacks utilizing many agents. 

D. Organization 

The reminder of this paper is organized as follows. Section 
|H| presents an outline of our attacks, and 'breaks' them to 



modular structure of building blocks. Section 
port de-randomization algorithm. Sections [IV 



Ilh presents our 
and [V] presents 



our sequence number inference technique, for the server and 



client numbers, respectively. Section VI presents and evaluates 
the off-path variants of the Ack-Storm and Optimistic -Ack 



attacks and Section VII builds on these attacks to perform a 



variant of the Coremelt attack with agents with low-privileged 
malicious agents. Section |VIII| presents defense mechanisms 
that can be deployed in either the client or the server. Finally, 



Section IX presents our conclusions from this work. 



II. Background and Building Blocks 

In this section we divide the TCP injection technique into 
building blocks which form a general scheme for performing 
an off-path TCP injection attack. This scheme is modular: each 
building block is a closed component, that can be implemented 
in several ways under different assumptions. Indeed previous 
off-path TCP injections El, (22J, D2) follow this scheme. 
We present a high level description of each step and compare 
implementations of the same block in previous attacks. The 
reminder of this section describes each of the building blocks 
and compares their implementation in existing attacks. Table 
[I] presents a summary of the discussion below. 

A. Identify Victim-Connection 

Our first building block is to identify a TCP connection 
to attack, i.e., a victim-connection. In [18j the adversary 
actively scans the client machine to existing connection with 
a particular server. As indicated within [18], the technique is 
often detected and blocked firewalls. In ll22l . Mallory runs a 
malicious application on the client machine (Android). The 



adversary uses this application to monitor connections from 
the client machines (e.g., by executing netstat). 

In this work we assume that Mallory runs a puppet, i.e., 
script in browser's sandbox and use this puppet to establish 
the connection to which we inject traffic. We refer to this 
connection as the 'victim-connection'. A puppet can cause the 
browser to establish a connection with a server of choice by 
requesting an object such as an image to embed in a web 
page, e.g., (img src="http://www.server.com/img.jpg"\mskip\ 
medmuskip The same technique was used in lfl3l . 

Once the adversary identifies that a connection between the 
client and a server exists, she aims to leam the TCP four tuple, 
i.e., IP addresses and ports of both peers, these parameters 
identify the TCP connection. The adversary in [18] receives 
the four tuple as result of probing. An adversary running 
malware as in El obtains this information directly from 
netstat output (or reading the corresponding file in procfs). 

A puppet is more limited than malware and does not have 
access to operating system information. In both puppet based 
techniques (this paper and iTPJl ) the adversary establishes the 
connection. Therefore, three of the parameters in the TCP 
four tuple are known: the client IP address, since the client 
is connected to the www.mallory.com; the server IP address 
and port, since the attacker chooses the remote-end for the 
connection. Hence, it is only left to identify the client port. 
In lfT3l the authors exploit the sequential port allocation im- 
plemented in Windows; this predictable allocation mechanism 
allows the adversary to guess the correct port of the connection 
that the puppet established. 

However, many operating systems make efforts to avoid 
predictable port allocation, as recommended in [19]. Transport 
layer client port randomization is a common countermeasure 
against off-path ('blind') attacks; it was proposed as patch 
to many attacks, including TCP RST attack EJ and DNS 
poisoning [16|. Since the adversary cannot observe the traffic, 
unpredictable client port provides an additional 16-bit random- 
ness that the blind adversary must 'hit' in order to tamper with 
the communication. 

We focus on one of the algorithms, Simple Hash-Based Port 
Selection, recommended in |[T9l and implemented in Linux. 
This algorithm uses a random initial port for every destination; 
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the port number is incremented for every connection. While 
Ma I lory cannot observer the port that C uses to communicate 
with S (cannot eavesdrop), we show how she can use the 
puppet to: (1) open multiple connections between C and S, 
and (2) learn the value of one of the allocated ports. 

After such port is obtained, a binary search is performed 
to obtain the last (highest) port that the C allocated. This 
allows the adversary to identify client ports used in following 
connections between C and S since following client-ports will 
use the same counter. 

Our technique is based on the Indirect Rate Reduction 
attack, that fakes TCP congestion events. This attack was 
suggested in IPT41 to identify the existing of TCP connections 
via the Tor anonymity network. We perform this rate reduction 
attack on different client ports and identify that a connection 
exists through a particular client port if the puppet observes 
a rate reduction, as follows from the TCP specification (cf. 
an operating system flaw as used in |[T3l ). Our technique 
can possibly precede other off-path attacks to bypass port 
randomization protection (for TCP). 

B. Learn Victim-Connection Sequence Numbers 

Once Mallory has identified the victim-connection, she 
learns the sequence numbers; knowledge of these parameters 
allows her to inject data to the connection. Observing the 
sequence numbers directly from traffic requires either an on- 
path attacker or privileged malware. Therefore, this option is 
unavailable for the weak attackers considered in lfT8l . iTOl . 
[22 1 and this paper. Off-path TCP injection techniques provide 
different methods to infer on the sequence numbers. We briefly 
describe existing techniques and the one presented in this 
paper. 

We present a new TCP server sequence number inference 
attack, that uses a radically different approach than the previ- 
ous attacks. Specifically, the attacker sends to the client data 
spoofed as coming from the server; by cleverly manipulating 
client queries, we are able to actually read such data when 
it falls into the flow control window. The data contains the 
server sequence number, hence, when read by our puppet, the 
puppet learns the server's sequence number. While this attack 
has to be done carefully to avoid connection reset, the result 
is extremely efficient attack. We next describe this technique, 
but before that, we recall for completeness the techniques used 
in previous works. 

1) Windows Specific, Bidirectional Exposure: In the Win- 
dows TCP sequence number exposure attacks |fT3ll , |fl8l , the 
adversary exploits the global counter IP-ID implementation in 
Windows. Mallory observes the difference in the IP-ID field in 
packets that she receives from the client machine which tells 
the number of packets that the client machine sent to other 
destinations (since each packet increments the IP-ID). 

In this technique, the attacker sends to the client crafted 
spoofed packets (appear to be sent from the server). The client 
responds to these packets only if they do specify incorrect 
server sequence number, i.e., outside the client's flow control 
window. The client sends the response to the server and 



Mallory learns whether the client responded by observing the 
IP-ID field (in packets that she receives). After learning the 
server's sequence number, the techniques in ||T3l . Ifl8l exploits 
Windows TCP implementation which filters incoming packets 
according to their acknowledgment numbers (this mechanism 
is not standard). This implementation allows the adversary to 
learn which acknowledgment is valid (passes filtering) using 
a similar side channel as the IP-ID. The acknowledgment 
number that the client expects to receive is close or equal 
to his sequence number. 

2) Unidirectional Sequence Number Inference Attack: In 
the sequence number inference attack [22], the adversary sends 
spoofed packets to the client machine. Each packet specifies a 
different, guessed sequence number. The observation in ll22l is 
that if the sequence number is not close from the value that the 
client expects (i.e., the sequence number that server will next 
use), then a firewall connecting the client to the network might 
discard this packet. According to measurements in ll22l 31.5% 
of cellular carriers in the United-States deploy firewalls which 
filter TCP packets by their sequence numbers; hence, their 
costumers are vulnerable to the sequence inference attack. 

The paper suggests two side channels that allow the adver- 
sary to learn the current value of the counter. The first aids 
globally incrementing IP-ID that might be deployed on routers 
and other intermediate middle boxes. The adversary sends a 
probe packet, spoofed as arriving from the server, that has TTL 
value high enough to pass the firewall, but low enough to be 
discarded by a following router; this packet will cause the 
router to send an ICMP feedback to the spoofed source. The 
adversary then sends a similar (but non-spoofed) packets to the 
victim and learns according to the difference in IP-ID whether 
the middle box responded to the probe. Another information 
channel suggested by l22l is using the malware running on the 
client to directly read a system file (under procfs) that specifies 
the number of packets that arrived at the client machine since 
boot time. Mallory learns that the sequence number specified in 
a probe passed firewall filtering if that counter increments (i.e., 
client receives probe). The malware monitors this variable and 
informs the attacker whether her packet arrived at the victim. 

In this case that Mallory's probe passes firewall filtering, she 
identifies that the sequence number specified in the probe is 
close to the correct sequence number. Once the attacker finds 
some sequence number in the firewall window, she efficiently 
finds the beginning of the window using a binary search. 
This attack exposes the server's sequence number, allowing 
the adversary to inject data as the server, but not the client. 

3) "Inject and Observe", Bidirectional Sequence Number 
Inference Attack: In this work we present a new technique 
that allows an off-path adversary to learn the value of both 
sequence numbers. Our technique assumes a standard TCP/IP 
implementation (cf. to lfT3l ) and does not rely on leakage 
via the IP-ID. Furthermore, since we assume only a puppet 
running on the client machine, the adversary cannot receive 
feedback from system files. 

Our technique is divided into two phases. In the first step, 



described in Section IV Mallory learns the server's sequence 
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number. In this step Mallory tries to inject a probe packet to 
the victim-connection; if successful, the puppet receives the 
injected data which contains the sequence number specified 
in the probe. The probability that Mallory exactly the next 
sequence number in the probe packet is low (232). However, 
Mallory has a reasonable probability to specify a valid se- 
quence number, one that is in the client's flow control window. 
We therefore send a probe that has meaningful parsing even 
buffered in the client's queue and is partially overrun by 
genuine segments from the server. 

Successful learning of the server's sequence number is 
required to perform the second phase, described in Section 
[V] where Mallory learns the client's sequence number. We 
employ a similar approach, however, knowledge of the server 
sequence number allows sending packets that are discarded 
if they specify future acknowledgment number and accepted 
otherwise. This allows us to perform a binary search for the 
acknowledgment number that the client expects (which equals 
his sequence number). 

In this step of the attack, the adversary sends a spoofed 
packet to the client as the server, that specified correct se- 
quence number (learned in previous step) and an Ack number. 
This packet is discarded if its Ack number is higher than the 
client's sequence number (i.e., packet Acks something not yet 
sent) and reaches the application otherwise. This step can also 
extend the technique in 11221 to allow bidirectional injection 
i.e., allow the attacker to inject data to the server-side as well. 

C. TCP Injection: Exploits 

TCP injections have several exploits. Zhiyun et al. [22| show 
that these can be exploited to perform cross-site scripting and 
request forgery, Gilad et al. |f]~3Tl show an additional exploit for 
sophisticated phishing. In this paper we show a new type of 
exploit: enhancing denial of service (DoS) attacks. We show 
that by employing TCP injections, the adversary can perform 
DoS attacks using puppet-nets that are equally as powerful 
to botnets (i.e., controlled machines). As argued in (4), it 
is relatively easy for attackers to control a large number of 
puppets (cf. bots). 

Scripts running in browsers have limited ability to launch 
DDoS attacks. One reason is limitations placed by browsers on 
the number of concurrent connections opened by the browser. 
Another reason is that, due to their execution within a sandbox, 
these scrips can only use standard TCP connections. In partic- 
ular, if the attack succeeds in causing congestion and loss, then 
TCP connections, including those of the puppets (scripts), will 
significantly reduce their window size (and hence their traffic 
rates). Therefore, while malicious Java Scripts can be used for 
DDoS attacks, their impact is much less than that of 'regular' 
malware (zombies/bots). We show in Section [VT] how by using 
TCP injections, the adversary can persuade the server to send 
data in high rates, which is typically higher than the client's 
bandwidth. 

In contrast to the data integrity exploits presented in ll22l 
and [13 J, the DoS exploits that we present use TCP control 
plane to cause congestion. Since there is no attempt to inject 



data to the application layer, even SSL/TLS protected sites are 
vulnerable. Hence, these exploits are applicable on websites 
that support HTTP connections, with or without SSL/TLS Q 

1 ) Denial of Service Exploits: We show how a spoofing, 
off-path attacker, who controls a limited number of (weak) 
puppets, can deploy formidable DoS attacks, which so far 
were known to require stronger attacker capabilities: the Ack- 
Storm attack [2] and the Optimistic-Ack attack E4l . Both 
are DDoS attacks, which use TCP control plane to generate 
excess amount of traffic. The Ack-Storm attack [2], is usually 
performed by MitM adversaries, possibly with limited eaves- 
dropping abilities. The Optimistic-Ack attack [24] typically 
requires client cooperation (zombie) and persuades the server 
to send data in a high capacity, more than that allowed by C's 
link. Since in both these attacks Mallory injects data only to 
the TCP layer (and not to the application), these attacks also 
work when the victim servers use SSL. 

2) Large Scale DoS Attack: By launching the presented 
off-path clogging attacks cleverly, simultaneously on multi- 
ple client-server pairs, an attacker (Mallory) to conduct an 
improved variant of the Coremelt attack l25l and congest a 
core link of the Internet, using only puppets. We explore this 
attack vector and introduce appropriate model and optimiza- 
tion problem for the attacker, to evaluate the most effective 
attack. Given a network graph, puppet locations and nodes to 
disconnect from one another, the attacker establishes victim- 
connections to servers, chosen according to their locations 
in the network. DoS attacks based on TCP injections are 
employed to disconnect victim nodes (e.g., an autonomous 
systems) from the network. 

III. Identify Victim Connection: A Puppet Only 
Technique 

The first step in performing a TCP injection as described 
in the previous section is to identify the victim-connection. 



As described in Section II-A since the adversary uses the 
puppet to establish the victim-connection, she knows the client 
address as well as the server address and port. In this section 
we describe a new technique that allows an off-path adversary 
running a puppet on a victim machine to learn the forth 
parameter of the TCP four tuple: the client port. 

As noted in Section [Tl-A| the client port is often randomized 
by the operating system. Larsen et al. suggest in RFC 6056 
|fl9ll four client port allocation algorithms that are secure 
against a blind adversary trying to identify the client port. In 
this section we focus on the third suggestion: 'Simple Hash- 
Based Port Selection'. This algorithm is used by the Linux 
kernel in versions 2.6.15 and above, i.e., from the year 2006; 
therefore, it is embedded in all Android versions. In Simple 
Hash-Based Port Selection, the operating system chooses a 
pseudo-random initial port for each destination (server), then 
for each new connection that the client establishes with that 
destination, the current port is used and then incremented. 

'For SSL/TLS websites, our exploit requires a different sequence numbers 
exposure technique, i.e., those in 1181 , 1221 . 1131 . as the one in this paper 
relays on injection of data. 
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Fig. 2. Port De-randomization, Step 1: Establish new connection to S. 



This protocol should be secure against off-path adversaries 
since these are not aware of the initial port. In the technique 
that we present below, the off-path adversary uses the puppet 
running on the victim to (1) establish multiple connections to 
the server, (2) time the server response time. The technique 
has two repeated steps which we describe below, iteration 
eliminates half the possible ports as used in the connections 
established by the puppet. 

The technique that we present below is executed in itera- 
tions; each iteration eliminates half the possibilities for client 
ports used in the connections allocated by the puppet. An 
iteration is composed of two steps which: (1) connections 
establishment, and (2) port elimination. 

A. Step 1: Open Multiple Connections to S 

A script running in browser context does not open a con- 
nection directly; instead, the browser establishes a connection 
with the server S when the script requests an object from S 
(e.g., to dynamically embed a remote image to a web page). 
However, a new connection is established only if there is no 
existing connection with S (otherwise, request is sent on the 
existing connection). 

The adversary uses the puppet (script) to establish n > 1 
connections to the server by manipulating DNS mapping 
of attacker controlled domains. The puppet requests an ob- 
ject from wwwl.mallory.com,. .. ,wwwn. mallory.com; since 
Ma I lory controls the DNS records for these domains, she sets 
the mapping of the domains to the same IP address, that of the 
S. Browsers use domain-names to identify servers (cf. to IP 
addresses); hence, this technique, which we verified on Firefox 
and Chrome, opens n new connections to S, where n is the 
maximal number of connections allowed (see value of n in 



Subsection III-C i. According to the port allocation algorithm, 



the ports used in these connections are sequential, we use this 
observation in the following step. Figure [2] describes this step 
of the attack. 

Note that in the following iteration, when the puppet will 
open a new set of n connections to S, connections opened 
in this step will be automatically closed by the browser, that 
usually closes the least recently used connection when out of 
resources (i.e., number of connections exceeds n). 

B. Step 2: Port Elimination 

In this step, illustrated in Figure [3] Ma I lory sends probes to 
the client C. These probes are spoofed and appear to be coming 



from S. The destination port (i.e., client port) specified in the 
probe packets is the one tested by the adversary. Probes are 
crafted to persuade the receiver to respond with a duplicate 
Ack if they belong a connection, i.e., the destination port is 
one of those allocated by the client machine in the first step. A 
sequence of three duplicate Acks that C sends S will slow the 
connection, this effect is measured by the puppet who notifies 
Mallory. 

A probe packet is a TCP packet that specifies a random 
sequence number; we assume the likely case, that this 32- 
bit field is out of C's flow control window. In this case, 
according to the TCP specification [21] (page 69), the receiver 
immediately responds to the source with a duplicate acknowl- 
edgment. A sequence of three duplicate acknowledgments is 
interpreted by TCP as loss and will cause the sender (S) to exit 
TCP slow start and enter congestion avoidance state. In TCP 
slow start, the congestion window (cwnd), which decides the 
number of packets that can be transmitted in a round trip time 
(i.e., without receiving an Ack) grows exponentially, while in 
congestion avoidance it grows linearly. Furthermore, a loss 
event will significantly reduce the congestion window (up to 
half the original size). 

In the elimination step Mallory sends three probes to all 
ports p = offset (mod 2 l n), where i is the current iteration 
number and offset is initialized to 1 and updated every itera- 
tion. In each iteration, the puppet requests a small object from 
all connection ports that she established, this by requesting an 
image from wwwl — n. mallory. com. The puppet times each 
response and tests whether the time to load one object was 
significantly longer than others (in our experiments average 
measured increased by more than 120%). The feedback that 
the puppet returns to Mallory is a bit: b = if there was a 
longer response, indicating that Mallory had probed one of the 
connection ports, and b = 1 otherwise. 

The probes need to be synchronized with a puppet request 
for an object: although not written in the specification, we have 
found that many web-server (in particular those running Linux) 
validate when they receive three duplicate acknowledgments 
that there are at least three packets 'in-flight' (i.e., un-acked) 
that they have sent to the client. Therefore, the restriction 
is that the client sends the duplicate acknowledgments after 
sending the request to the server. If there is no reordering 
in the network, this method ensures that the server will send 
the response before handling the duplicate acknowledgments. 
Notice that the client sends the duplicate Acks before actually 
receiving the server's response. We refer to this time frame in 
Figure [3] as the Mallory's probe sending window. 

At the end of the step, Mallory updates the attack state 



according to puppet's feedback: offset 4— offset - 



-b-2 l 



The reason that n is always added to the offset is to account 
for the n connections established in this iteration. After the 
final port elimination step, the value p indicates a connection 
port. 
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measure rate; port 2kn + 1 is a connection port. 



C. Implementation and Limitations 

The Linux kernel chooses client port from the range 
[32768,61000] this is significantly a smaller range than all 
available ports, i.e., [1,2 16 — 1]. This observation to im- 
prove the search run time (only probing ports in the smaller 
range). The maximal number of connections that the puppet 
may open, i.e., n, changes according the version of the 
browser. However, this value is at least 32 in modern browser 
and typically increases with new releases J9j- These num- 
bers imply that port de-randomization technique will require 
|~log 2 (61000 — 32768)] = 15 iterations to complete, and 



15 28232 
i 32-2* 



= 883 



Mallory will send Ef 6100 °7 2 f 768 = £ 
probe-triplets. 

The first requirement of the port exposing technique is that 
the web pages support persistent HTTP connections. In such 
connections, all requests are over the same (victim) connection 
and ensure it does not close. Persistent HTTP connections 
are the default configuration of apache servers and are also 
employed by many large web-servers (e.g., Facebook, Yahoo!, 
Google), but not all (e.g., live.com). We require persistent 
connections since otherwise, the connections opened in step 1 
of this attack will close by step 2. 

The second requirement of the port exposing technique is 
that the connection will not enable the selective acknowl- 
edgment (SACK) TCP option. This option allows the re- 
ceiver specify exactly which packet arrives when sending 
an acknowledgment. The three duplicate acknowledgments 
sent in our attack are identical (specify the same SACK 
option), i.e., indicate that no server packet had arrived be- 
tween these packets. In this case the server, who receives 
these acknowledgments, may treat these as a single duplicate 
acknowledgment and will not reduce the rate. We also specify 
this mechanism as possible defense in Section [Viri| (Defenses). 

Figure |4] shows the portion of 1000 web-servers that comply 



1 

0.9 
0. 
0.7 
0.6 
0.5 




i — 1 . Persistant connections 
-x— 2. SACK disabled 

3. Both persistant connections and SACK disabled 



16 32 64 128 256 512 
Number of Top Web-Sites Tested (log scale) 



1024 



Fig. 4. Portion of popular websites that comply with attack requirements. 



with either and both these requirements. 

D. Empirical Evaluation 

We evaluated the port exposure attack described in this 
section. Our initial results show that the technique has high 
success rate (over 70%). We are currecntly working on further 
improving theses results. In the following versions of this 
paper we will include details and graphs on our experiments. 

IV. Search for Server's Sequence Number 

In this section we present the first phase of "inject and 
observe", a technique for learning the sequence numbers used 
in the victim-connection; we follow the high level design 



presented in Section II-B3 At the end of this phase Mallory 
learns the server's sequence number; this allows her to send 
data to the client impersonating as the server. We assume 
that Mallory has the parameters of the victim-connection, in 
particular, that she identified the client port; e.g., by executing 
the technique described in the previous section (or other 
methods, see Table [TJ|. 

Subsection I V-A| provides required background, explaining 
how browsers handle HTTP responses that they receive. Sub- 
section [TyjB] describes our search technique. In the following 
section we present the second phase of "inject and observe", 
where Mallory learns the client's sequence number; in that 
section we provide an empirical evaluation for the entire 
procedure. 

A. Browser HTTP Request/Response Handling 

Browsers support persistent HTTP connections and request 
pipelining since HTTP 1.1 (' 1121 '). These allow sending of 
multiple requests to the same server in pipeline over a single 
TCP connection. The responses from the server are buffered 
and ordered according to the browser's flow control window, 
denoted by wnd (allocated per-connection). This window is 
important to our attack; it specifies the range of disordered 
bytes that the TCP receiver (browser) can keep, its size 
is typically 2 16 . Data bytes whose corresponding sequence 
number is in cwnd are buffered in a receive-queue for the 
application (browser), other arriving data is discarded. 
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The browser keeps a queue for transmitted HTTP requests 
and waits for a response if that queue is not empty; i.e., reads 
from the TCP 'received-buffer' until reading a full response. 
The response's HTTP layer is parsed and its encapsulating 
data is then embedded in the web page, the request is removed 
from the queue. This process continues until there are no more 
requests awaiting reply from the particular connection. 

Unfortunately, the HTTP specification does not tell the 
appropriate action when a response does not have a valid 
HTTP header (i.e., parsing fails). The de-facto standard, used 
by current versions of Internet Explorer, Firefox and Chrome 
(and possibly other browsers as well) encapsulates all data that 
is available for reading, i.e., sequence of received bytes starting 
from the low bound of cwnd, under the following single HTTP 
header: 

HTTP/1.1 200 OK 

Content-Type: text/html; charset=us-ascii 
Content-Length : available-data-size 

Browsers do not break the existing TCP connection in this 
case and continue processing requests over it. We believe 
that this behavior, which essentially displays content data as 
plain text, was introduced in early days of the Internet to 
handle misbehaving servers and was mimicked in modern 
implementations. The following subsection explains how this 
behavior is exploited to learn the server's sequence number. 

B. Inject and Observe 

In this subsection we present the server sequence number 
learning technique which is illustrated in Figure [5] The search 
has two steps 'Inject' and 'Observe'. 

In the Inject step, illustrated by the top packets in Figure 
[5] Mallory sends spoofed packets that appear to belong to the 
victim connection. Each of these packets specifies a sequence 
number that is \wnd\ greater than the previous one. Mallory 
writes (as part of the TCP data) the packet's sequence number 
and prependers it with padding. 

All the packets that Mallory sends except for one are 
immediately discarded by C since the sequence number that 
they specify is out of wnd boundaries. For simplicity, we 



2|wnd|.. 



cwnd shifts forward for every request 



Fig. 6. The state of wnd after 'Inject' step. 



assume that the packet that is saved in C's buffer does not 
begin at the lowest offset in wnc^ C responds to every packet 
that Mallory sends with a duplicate Ack; this will cause 
connection slow down (but not breakdown) as we exploited in 
the previous section, however, this does not effect the sequence 
number learning process. 

There is an additional validation that is performed on 
the acknowledgment number specified in received packets. It 
verifies that the packet does not specify a future Ack; we refer 
(and exploit) to this condition extensively in the following 
section. In this section the attacker is therefore required to send 
two packets for each sequence number, one specifies Ack = a 
and the other specifies Ack = a + 2 31 ; ensuring that the Ack 
in one packet is valid. 

After this step, C's victim-connection wnd is as illustrated 
in Figure [6] 

In the following Observe step, the puppet requests objects 
from S. It ensures that there is always at least one request 
waiting for reply in the browser's queue; this by generating 
two initial requests and sending a new request when a response 
arrives. See illustration in Figure|5] The reason that one request 
must be in queued is that when there are no pending requests, 
some browsers clear the receive buffer (those will discard the 
injected data); this behavior was verified on Mozilla Firefox 
and Google Chrome. 

Each response that arrives at C shifts cwnd forward; eventu- 
ally, the injected data that was saved in the previous step will 
be used as a response. Some of the last server's response might 
overlap the injected data. The TCP specification determines 
that in this case the more recent data is used, this essentially 
means that some of the injected data will be lost. The 
padding that prepends the sequence number in the response 
is dispensable data, that is of the server's response size; it 
ensures that the sequence number value is not overrun by a 
server's response. 

The requests that the puppet sends are for arbitrary objects 
that will yield an HTTP 404 response (object not found). The 
reason that we prefer receiving such responses is that they 
are relatively short which reduces the amount of data that the 
adversary sends. Furthermore, using such requests makes the 
attack generic: Mallory need not identify specific objects to 
obtain for every remote server she uses. 

When the puppet reads a response that does not specify 

2 The probability that this event occurs is rather small: /J " Cl t^/jr J?fj ' < 
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'object not found' it sends the response to Mallory who finds 
the sequence number; adding the length of the packet she sends 
she identifies the next sequence number. [^] 

The technique that we presented in this subsection requires 
the adversary to send a number of packets that is linear to 
the number of sequence numbers. Specifically, the adversary 
sends during the 'Inject' step 2|ie = 2 17 packets. 

V. Search for Client's Sequence Number 

In this section we present the second phase of the 'inject 
and observe' technique. At the end of this phase Mallory learns 
the client's sequence number; this allows her to send data to 
the server impersonating as the client. We show how Mallory 
can perform a binary search for the Ack number that the client 
expects which equals the sequence number that the client will 
next send. This step assumes that Mallory has the parameters 
of the victim-connection and learned the server's sequence 
number. Our technique also extends the one presented in El 
which detects the server's sequence number. 



Subsection V-A provides necessary background on TCP's 



packet processing, Subsection V-B presents the binary search 
technique. 

A. TCP Receiver Packet Handling 

In the technique that we describe in the following subsection 
Mallory learns whether some acknowledgment number is 
above or below the sequence number that the client will next 
use, denoted by NXT. Since the sequence number is a cyclic 
field, when we write above or below, we refer to the drawing 
in Figure [8] The figure illustrates a division of the Ack field 
values into three intervals: in the gray area (sent and Acked) 
and the black area (sent, but not Acked) are numbers below 
NXT. In the white area are sequence numbers above NXT. 

The test is derived from an observation from the TCP spec- 
ification [21] (Section 3.9, page 72). The relevant statement 
refers to an acknowledgment packet that carries data and 
contains a valid sequence number; i.e., success in learning 
the server sequence number is required to initiate this phase. 
The specification distinguishes between two cases regarding 
the acknowledgment number in the packet. 

Case 1: the packet contains a duplicate Ack (gray area 
in Figure [8]), or acknowledges data that was sent, but not 
already acknowledged (black area in Figure |HJ. In this case, 

3 Since the puppet (Java Script) runs in context of Mallory domain, they 
can communicate without restrictions. 



Fig. 8. Ack Number Map. UNA is the lowest unacknowledged sequence 
number, NXT is the next sequence number that C will send. The 32-bit Ack 
field is cyclic. 



the recipient continues processing the packet regularly (see 
ETIn and the application will receive the data bytes. 

Case 2: In the complementary case, that the acknowledg- 
ment number is for data that was not yet sent (white area in 
Figure [8}, the recipient discards the packet. 

B. Inject and Observe 

We now describe the Inject and Observe technique to learn 
the Ack value. Each iteration of Inject and Observe eliminates 
half of the possible values to the Ack field. We initiate this 
phase assuming that all Ack values are possible. Let ack-low 
denote the lowest possible value for the acknowledgment field 
and let I denote the number of possible values for the field; 
initially, ack-low = 0,1 = 2 32 . 

In every iteration of the search the puppet requests a HTML 
page and the adversary provides a response injected to the TCP 
stream by specifying the server's sequence number learned 
in the previous step, denoted by a. The adversary sends two 
HTTP responses that specify different pages: r\ and r^. The 
response packets specify the acknowledgment numbers a' = 
ack-low, a" — ack-low + hi. According to the observation 
above, one of these packets specifies an Ack that is not above 
the true Ack value that the recipient expects (NXT) and will be 
discarded. Therefore, the puppet receives either r\ or and 
will report the result to Mallory. Figure [9] illustrates a search 
iteration. 

Let a be the ack number of the packet that arrive at the client 
(identified by puppet's feedback). After each iteration Mallory 
updates the parameters ack-low, I and a: ack-low <— a, I <— | 
and d 4— g + response-size in order to account for the injected 
data. 

1 ) Binary Search for a: The Inject and Observe technique 
above discovers the sequence number in a binary search 
methodology. The 'before' and 'after' terminology used in 
the TCP specification (illustrated in Figure [8} divides the 
possible values of the Ack field to similar-sized areas: the 
gray and white areas in Figure [8] are of equal size, and the 
black area (sent bytes without acknowledgment) is usually 
relatively small. Therefore, each iteration of the attack elimi- 
nates approximately half the possible values for the field. This 
allows Mallory to perform a binary search for NXT; each time 
eliminating approximately half the possible numbers. The 32- 
bit length of the Ack field implies that there are 32 iterations. 
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C. Empirical Evaluation 

We evaluated the inject and observe technique described 
in this section. Our initial results, which will be included 
in following versions of this paper, show that the technique 
has considerable success rate as a standalone componenet and 
when combined with the port exposure technique described in 
this paper (over 30% and 20% respectively). We are currecntly 
working on improving theses results. 

VI. Denial-of-Service Exploits 

We next describe possible exploits of long-lived-connection 
injection attacks to disrupt network communication. Namely, 
we show how attackers can build on off-path injection tech- 
niques, to launch formidable Distributed Denial-of-Service 
(DDoS) attacks. As before, we consider an off-path IP- 
spoofing attacker, who also controls a significant number of 
low-privileged malwares or 'puppets', i.e., scripts running in 
browsers of unsuspecting users. 

Performing typical denial of service attacks with weak 
malicious agents is challenging, as we motivated in Subsection 

nm 

A. Off-Path Optimistic Ack Attack 

We first describe Off-path Optimistic Ack; this is a variant of 
the Optimistic Ack DoS attack |24|. These attacks cheat TCP's 
congestion control mechanism, causing senders to believe that 
most of the data they sent was already received, and hence 
that they can send more data (congestion window is not full), 
and also to increase the size of the congestion window and as 
a result, the sending rate. This can result in huge amplification 
factors, see J24|, unless servers use per-connection bandwidth 
quotas or use other defenses. 

In both Optimistic Ack attacks (ours and the original l24ll ). 
the attacker sends to the server acknowledgment packets 
(Acks), as if the client received all packets sent by the server 
(although packets are still in transit or even lost). As a result, 
the server continues sending information, with increasing 
rates. 

In the original attack 11241 . the client must run malware, 
with ability to send 'raw IP' packets (i.e., not according to the 
TCP specifications). This is a significant requirement; recent 
operating systems make it harder for malware to obtain such 



ability, which may only be available to privileged (i.e., 'root') 
programs. Furthermore, the original attack may be blocked by 
a firewall on the client side, by detecting the unusual high 
rate. Note that since by requiring only puppets, attacker is 
more likely to control enough clients to succeed in the attack, 
in spite of server-side countermeasures such as per-connection 
quotas. 

1) Off-Path Variant Attack Process: A TCP injection attack 
allows an attacker to perform an off-path variant of the 
Optimistic Ack attack as follows. The attacker only needs a 
puppet on the client machine to open the TCP connection 
with the victim server and learn the client port and sequence 
numbers. Following this, the puppet requests some large object 
from the server and is no longer needed; the attacker sends 
Ack packets as done by the client in the original attack, and 
- if not using SSL/TLS - the attacker can even send new 
request(s) if needed (instead of the client). Note that even 
if the client's firewall detects the attack and begins blocking 
packets on this connection from both directions, this does not 
help since we provide the Acks to the server from the off- 
path attacker. Furthermore, RFC-compliant RST packets that 
the firewall (or client) may send, would be out of the server's 
flow control window and hence ignored, and would not tear 
the connection. Server-induced verifications, by intentionally 
dropping or reordering packets periodically, as suggested in 
l24l . seem one of the best (or only) defenses. 

B. Off-Path Ack-Storm DoS Attack 

In the original Ack-Storm DoS attack [2|, the attacker needs 
to have some ability to eavesdrop on packets. From these 
packets, the attacker learns the TCP parameters (IP addresses, 
ports, and sequence numbers). Using these, the attacker sends 
two spoofed data packets, one to each of the two ends of 
the connection. According to the TCP specification, and in 
most TCP implementations, upon receiving an Ack for data 
that was not yet sent, TCP sends back a 'duplicate Ack' - 
i.e., resends the previously sent Ack. As a result of receiving 
the pair of spoofed data packets, one at each peer, both peers 
begin sending acknowledgment packets to each other. Since 
these Acks acknowledge data which was actually sent by the 
attacker, not by the peer, then each of these Acks will only 
result in another duplicate Ack returned, and this 'ping-pong' 
process will continue indefinitely. 

The attacker can send additional data packets to the peers, 
causing additional ping-pong exchanges, quickly filling-up the 
channel capacity. This causes increased load on the networks; 
the fact that the packets involved in the attack are very short 
(just Acks), makes the load on routers and switches even 
higher. Eventually, this causes packet losses, and legitimate 
TCP connections sharing the same links significantly reduce 
their rate. 

1) Off-Path Variant Attack Process: The off-path Ack- 
Storm DoS Attack works exactly like the regular Ack-Storm 
DoS Attack, except for employing the injection techniques to 
allow the off -path attacker to learn the TCP parameters. Hence, 
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the attacker can run this attack without requiring the ability to 
eavesdrop. 

C. Empirical Evaluation 



Fig. 11. Evaluation of Ack-Storm and Opt- Ack DoS attacks. The legend 
indicates for each line the type of attack and the peers in the legitimate 
connection (that Mallory degrades). Measurements are the average of 50 runs, 
error-bars mark the standard deviations. 



We used the topology illustrated in Figure 10 to test the off- 



path denial of service attacks that we presented. In our tests 
we assume that Mallory runs a puppet on C and can inject 
data to the TCP connection between C and S (a connection 
that Mallory caused C to establish). 

We measure the degradation of service that these attacks 
cause to other legitimate connections. We consider different 
round- trip times (RTTs) for the legitimate connections that 
we measure: the longer the RTT is, the greater the congestion 
windows. Since every loss halves the congestion window, 
a more significant effect is observed when RTT is high. 
Furthermore, a higher RTT implies that it will take more 
time for the legitimate TCP sender to detect a packet loss 
and retransmit. We compare the effect of these attacks to line 



1 in Figure 11 (base-line) which illustrates the time it takes 
C* to receive a 50MB file from S* under normal conditions. 

1) Off-Path Optimistic Ack Evaluation: In this attack we 
aimed to clog the S's link: Mallory uses C to request some 
large file from S and then performs the Optimistic Ack attack, 
persuading S to send data to C at high a rate. We evaluated the 
effect of this attack by measuring the degradation of service in 
a connection that S has with some other client C* who tries to 



download a 50MB file. Lines 1 and 2 in Figure 1 1 illustrate our 
results. Notice the significant difference in attacker and server 
link capacities; the amplification ratio measured in this attack 
is 78 (for every byte that Mallory sends, S sends approximately 
78 bytes). Furthermore, the attack also clogs C's link, as shown 
by line 4. 

2) Off-Path Ack-Storm Evaluation: We use the Ack-Storm 
attack to congest C's link and measure the effect on a different 
connection that he has with some other server S*. In order to 
congest the link, Mallory creates a new Ack 'ping-pong' every 
100 ms; to create each ping-pong Mallory sends only two short 
(40B) packets. In the connection with S*, C tries to download 
a 50MB file (similar to the previous experiment). Lines 1 and 
3 compare the file transfer time at a normal time, to that when 
the Ack-Storm attack takes place. This attack requires much 
less effort and lower bandwidth than the Opt-Ack attack, i.e., 
has much higher amplification ratio. However, the Ack-Storm 
attack is limited by the client bandwidth (which is typically 



lower than the server's); this limitation is illustrated by line 5 
which is very similar to line 1 (normal conditions). 

VII. Off-path Coremelt Attack 

The two DoS attacks which we described in Section [VTl can 
be launched using only puppets and have high amplification 
ratio, it follows that even relatively weak attackers may be able 
to cause large amounts of traffic from many clients spread 
around the network. This can cause high load on servers, 
routers and links. 

In particular, by choosing well the pairs of clients and 
servers between which the attacks are launched, the attackers 
can cause huge amounts of traffic to flow over specific 'victim' 
backbone routers and links. These backbone networks, con- 
necting large core ISPs (autonomous systems), have very high 
capacities; by sending enough traffic to a particular destination, 
attacker can cause queuing and losses in the connecting router. 
As a result, Internet connectivity may break - first for TCP 
connections and then even for UDP applications. 

We use the term Off-path Coremelt Attack for the resulting 
attack on core Internet connectivity, since it is an off-path 
variant of the Coremelt attack |25l . The Coremelt attack uses 
a large botnet, sending large amounts of traffic between pairs 
of the bots, with the pairs chosen intentionally so that huge 
amounts of traffic will flow over specific victim link/router. As 
shown by simulations in [25 1, this can result in congesting the 
victim link/router and breaking connectivity in the Network. 
We discuss the attack and analyse it, presenting an interesting 
optimization problem for the attacker; notice that similar 
analysis is applicable to the original Coremelt (and was not 
presented so far). 

A. Off-Path Variant Attack Process 

In the Off-path Coremelt attack, the attacker congests a 
core link or router; however, instead of depending on pairs of 
zombies (bots), here the attack just requires a puppet at one 
end. The other end of the connection is a legitimate server, 
and to cause huge amounts of traffic, the attacker uses one of 
the two off-path DoS attacks described above. 
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This attack has three advantages compared to the original 
Coremelt attack: (1) controlling a large and correctly-dispersed 
set of puppets is easier than controlling a comparable set 
of zombies; (2) we only need to control one end of each 
connection (puppet), not both ends; and (3) since we use 
adversary-chosen servers, these can have very high bandwidth, 
higher than available to most bots. 

B. Problem Statement and Adversarial Algorithm 

The off-path Coremelt attack involves a non-trivial opti- 
mization problem for the adversary, i.e., how to cause maximal 
damage using the resources available to her, namely, mainly, 
the bandwidth of the attacker, i.e., of the attacking node 
itself, as well as the capacities of its puppets. The damage is 
essentially measured by the number of disconnected < v. d > 
pairs, where v is a victim client and d is a destination (server 
that the victim needs to access). We note that both Opt-Ack 
and Ack-Storm attacks, utilize the unwitting cooperation of 
server machines at the other end of the connections; while in 
principle, such unwitting servers are also a limited resource, 
we believe that in practice there are so many such servers that 
we can safely ignore this limitation, as other limitations would 
almost always be the bottleneck. 

This 'real' optimization problem is quite complex; we 
present and analyze a version with several significant sim- 
plifications, which, nevertheless, results in a very effective 
attack, significantly improving compared to the 'original' off- 
core attack E51 . More detailed modeling and analysis, and 
more efficient algorithms, may allow an even more effective 
attack, and remain a challenge for future research. 

Intuitively, the goal of the attacker is to break connectivity 
between autonomous systems (ASs), by congesting links with 
excessive traffic. Notice that this ignores the possibility that 
it may be sometimes more effective to attack some intra- 
AS link, e.g., the 'last mile' connection of a particular host 
(destination server, or even client); we focus on 'core-melt- 
like' attacks, which focus on inter-AS links. Attackers can 
only further optimize by congesting intra-AS links, when it is 
more effective. 

We focus on significantly degrading the performance of TCP 
connections. TCP is the most widely-used transport protocol, 
and due to its congestion-control mechanisms, it is very 
sensitive to packet loss (as in a clogging attack); as explained 
in 0, a very low loss rate suffices to cause major degradation 
of TCP performance. In particular, sending roughly as many 
packets as the link capacity, surely ensures sufficient, even 
significant, loss rate. 

For clogging TCP connections, the attacker can utilize both 
off-path attacks (Ack-Storm and Opt-Ack), choosing effective 
mix of the two, based on the given topology of attacker pup- 
pets, victims and servers. The Ack-Storm attack requires the 
attacker to send new packets whenever on of the attack packets 
is lost; hence, it is only effective for low loss rates. Indeed, 
intuitively, the Opt-Ack attack seems much more effective, 
due to its huge amplification factor; in our measurements, we 
found average amplification factor of fi — 78, which is very 



impressive - although significantly less than the amplification 
reported by the original Opt-Ack research (and incomparable 
to the theoretical analysis presented there), see |24n For 
simplicity, in our analysis we simply assume that Opt-Ack 
attacks result in fixed bandwidth amplification of /i, i.e., if the 
attacker dedicates bandwidth of x bytes per second to Opt- 
Ack attack by sending it to a particular server s, injected 
into connection with some (attacking-puppet) client c, then 
the result is transmission of fi ■ x bytes from s to c. We ignore 
the (nominal) amount of traffic required for this attack by the 
client attacking-puppet c. 

In contrast, the Ack-Storm attack requires the puppets of 
the attacker to send one packet per each packet sent by the 
abused server at the other end of the connection. However, 
notice that Opt-Act amplification factor applies to packet 
sent by the attacker, not by the puppets; and with Ack- 
Storm, significant degradation is possible already with low loss 
rates, e.g., even 0.1% by our measurements, which essentially 
implies amplification factor of 1000 (for the packets sent by 
the attacker). Hence, for Opt-Ack attacks, the limiting factor 
is usually the capacity of the attacker (albeit amplified by fi), 
and for Ack-Storm attacks, the limiting factor is usually the 
capacity of the attacking puppet (without amplification). 

Hence, the following simplification seems reasonable; we 
assume that the attacker bandwidth is essentially used to its 
maximal capacity for Opt-Ack attacks, and the capacity of 
attacker-controlled puppets (puppets and marios) is used for 
Ack-Storm attacks, ignoring the small additional amount of 
attacker traffic required also for Ack-Storm attacks and the 
small amount of attacking-puppet capacity used for Opt-Ack 
attack. This allows us to design the attacker strategy in two 
separate steps: first, we analyze the best allocation of the 
attacker bandwidth to Opt-Ack attacks; and then we analyze 
the best allocation of the capacity of the attacker puppets, to 
Ack-Storm attacks. 

For both allocations, we assume that the adversary knows 
the topology and routing of the AS -level Internet routing 
network, for example, as provided by route views Q]. We 
model the topology of this network as a graph G = (A, E), 
where A is the set of Autonomous Systems (ASs), and E is the 
set of links (edges) between ASs. For every link (/, t) e E, let 
crf : t) S [0, oo ) be the capacity of (/, t). As explained above, 
the goal of the adversary is to clog one or more links, causing 
maximal damage, i.e., disconnecting the maximal number of 
< v, d > pairs; clogging link (/, t) € E essentially means 
causing Cff t) 01 more traffic to be sent over link (/, t). 

We assume that both attacker traffic and legitimate traffic, 
use fixed, known routes; for any given source AS s E A and 
destination AS d € A, let the route from s to d, denoted 
r(s,d) = {{fi,ti)}\ =1 , be a sequence of some number I of 
edges (in E), such that /i = s, ti = d, and for every i : 1 < 
i < I holds U = fi+%. 

4 We believe the difference between our results and these of [24], may be 
mostly due to differences in the (default?) quotas and other restrictions, of 
the web servers used. 
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Each of the relevant entities - victims, destinations, puppets 
and the attacker herself - reside in one of the ASs in A. For 
simplicity, we assume a single attacker, in a specific AS, with 
bandwidth a a', without loss of generality, we assume this is 
AS number 666. In contrast, victims, destinations and attacker 
puppets are spread among the ASs. For simplicity, we just 
consider two (potentially overlapping) subsets of A, denoted 
A v and Ad, and representing the ASs containing victims and 
destinations, respectively (i.e., we ignore the issue of how 
many victims and destinations are in each AS). Finally, for 
every AS a £ A, we let a a denote the (total) bandwidth of 
attacking puppets in AS a. 

For simplicity, we assume that every AS contains sufficient 
number of servers that the attacker can use in Opt-Ack and 
Ack-Storm attacks, to generate traffic. Let a a , s denote the 
amount of traffic used in Ack-Storm attack, from attacking 
puppets in AS a to the servers in AS s, and let ctA,c,s be 
the amount of Opt-Ack attack traffic that the attacker sends to 
server in AS s, for a connection with client in AS c. Clearly, 
we have the following restrictions, for every a € A: 
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We next require that the total traffic on each link, including 
Opt-Ack traffic (from attacker to server, and then, amplified by 
fi, from server to client) and Ack-Storm traffic (from client to 
server and back), is not greater than the link capacity, namely, 
for every (/, t) £ E, we have: 
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We denote the right term in Equation [3] by T(f, t), i.e., the 
transmitted communication over the edge (/, t). Finally, we 
want to maximize the number disconnected pairs < v,d >. 
We use the same criteria as the original Coremelt attack and 
consider a pair < v, d > disconnected if there exists a link 
on the route between them that is loaded up to its capacity. 
Denote by x <v .d> an indicator variable for clogged routes: 

x <v , d> = 1, If: 3 (f,t) e r(v,d) | c(f,t) =T(/,t) 
x<vA> = 0, Otherwise (4) 

Our goal function is: 

^ (5) 



max 

<v,d> 



solve it, i.e., find the amount of data sent by each attacking 
node to every server (denoted by a variables). However, the 
indicator variables defined in Equation [4]cannot be represented 
as linear terms since the quantitative '3' is not linear. We solve 
a relax version of the maximization problem where the target 
function and constraints are as the regular definition of the 
problem, but the definition of the indicator variables change. 

Let Cut(G) denote the minimal cut of the network graph G 
with respect to the sets of victims and destinations. For every 
pair < v,d >, denote by target(v,d) the edge with minimal 
capacity such that target(v,d) € r(v,d) and target(v,d) £ 
Cut(G). Define: 

%<v,d> = 1, K c(target(v , d)) — T (target (v, d)) 

x<v,d> = 0, Otherwise (6) 

In the relaxed version we target specific links in the route 
between victims and destinations, those that belong to the 
minimal cut. This restriction allows stating the attack as a 
linear programming maximization problem: the goal function 
is Equation [5] and the constraints are given by Equations 1 - 
3. 

VIII. Defense Mechanisms 

The attacks presented in this paper relay on successful 
exposure the client port and sequence numbers. In this section 
we propose remedies, mitigating the attack vectors considered 
in this paper. We describe both immediate patches that can be 
deployed with only minor modifications longer term remedies 
that require modifications to existing implementations and 
deployed devices. The remedies purposed below are of two 
types, those deployed at the client-end, and those deployed at 
the server-end. Each mechanism blocks the attack even if the 
other peer is vulnerable. 

A. Server-End Defense 

1 ) Mitigation for Client Port Exposure: A server can mit- 



igate the port exposure technique described in Section III by 



We have stated the off-path Coremelt attack as a maximiza- 
tion problem and would like to use linear programming to 



enabling the selective Ack (SACK) TCP option. This option is 
supported by most modern client operating systems (including 
Linux) and is usually advertised in the client's SYN packet. 
However, we found that web-server rarely enable this option 
which is therefore typically not employed (see measurements 
in Figure |4}. When the SACK option is employed, every 
Ack that the client sends to the server specifies the sequence 
numbers corresponding to data that was received. This allows 
the sender, in case that one of his packets is lost, to identify 
and resend only the lost packet. 

In our attack, the three duplicate Acks that the client 
sends result from three sequential (spoofed) packets that the 
adversary sends. The SACK field in these acknowledgments 
is identical and identifies that these packets did not originate 
from three server-sent packets (since otherwise, the SACK 
field in every duplicate Ack would have increased for every 
packet). The server should handle such multiple duplicate 
Acks with identical SACK fields as a single duplicate Ack. 
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The mechanism is already implemented in Linux (but typically 
disabled). 

2) Mitigation for Sequence Number Exposure: The tech- 
niques presented in Sections |IV||Vl for learning the client- 
server sequence numbers inject data to the TCP stream; 
injected data is then observed by the puppet who feedbacks 
the attacker. In order to ensure data integrity, cryptographic 
mechanisms should be deployed; i.e., servers should use 
SSL/TLS instead of relying on randomized initial sequence 
numbers for authentication. 

B. Client-End Defense 

1) Mitigation for Client Port Exposure: Clients can modify 
the port selection algorithm used by the operating system. Of 
the three remaining algorithms suggested in |fl9l , algorithm 
four is closely related to the Simple Hash-Based Port Selection 
algorithm exploited in this paper and might be vulnerable to 
similar attack. Hence other algorithms are preferred. 

However, in many cases modification of port allocation 
algorithm on the client machine does not suffice to prevent 
the attack. Many clients are connected to the Internet via 
NAT devices; these middle-boxes allocate each connection 
an external port and typically run an embedded version of 
Linux, i.e., use a vulnerable algorithm. Similar modifications 
are required to these devices as well. 

2) Mitigation for Sequence Number Exposure: The server 
sequence number exposure attack that we presented in this 
work exploits de-facto standard browser behavior which is not 
required by standard: display corrupt responses to the user. 
Browsers can modify this behavior and in case that a response 
does not pass HTTP parsing, send a TCP reset to the server 
and close the connection. This modification conforms with the 
HTTP standard and protects the user from the attack vector 
considered in this paper. 

IX. Conclusions and Future Work 

In this work present and evaluate a new technique for off- 
path TCP injections. We show that a common implementation 
of client port randomization is vulnerable to off-path prediction 
attack. We investigate known DoS attacks in a new setting, 
one where the adversary is able to inject data into the TCP 
connection and show that this allows their deployment under 
weaker assumptions: puppets instead of bots, off-path instead 
of on-path attackers. This work continues the line of recent 
works on TCP injections, showing that the folklore belief 
that TCP is immune to off-path adversaries is incorrect. We 
motivates deployment of cryptographic protocols to protect 
communication, such as SSL/TLS and IPsec and believe that 
a more significant portion of servers should use these defenses, 
even if communication is not sensitive. 

This work leaves several directions for future work. The 
first is to test the off-path Coremelt attack with simulations, 
extending these of [i25j (and comparing to their results). A 
second research direction is analyzing the security of the re- 
maining three port randomization algorithms suggested in 1 19 1. 
In particular, we believe that the fourth algorithm suggested 



in |fl9l , Random-Increments Port Selection, is likely to be 
vulnerable to a variant of the attack we described in this paper. 
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